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METHODS, SYSTEMS, AND SOFTWARE FOR PROVIDING SERVICE 

INTEGRATION FRAMEWORK 

BACKGROUND OF THE INVENTION 

[0001] The present invention generally relates to computer and Internet technology, 

and more particularly to technology for providing a consistent mechanism for systems (such 
as vendor systems) to access back-end functionality and data from services that deal with 
the public. 

[0002] Typically, front-end business applications have been integrated with back- 

office host and network-based applications through a complex and non-standard set of 
APIs, adapters, and services. This may be thought of as a product-driven approach, since it 
has multiple products interfacing with the back office, each through its own set of 
integration, access, and security mechanisms. 

[0003] There are a number of problems associated with this approach. For example, 

multiple database-specific access methods may be required. There may be several ways to 
do the same thing. There may be no organized way to provide audit information, and 
diagnostics maybe distributed throughout the environment (e.g., in event logs and text 
files). 

[0004] Regarding the back-end, there may be multiple vendor-supported 

middleware solutions in place, and there may be direct coupling of applications to an 
individual connectivity utility. 

[0005] Regarding security, there may be no single client authenticator allowing a 

user to interface with multiple applications, and there may be multiple entitlements systems. 
The security may be integrated with channel frameworks, and there may be inconsistent 
representation of processes and data. 

[0006] Such approaches typically evolve through a history of developing redundant 

and diverse technologies as new infrastructure components are added for each new project. 
As a consequence, they have a number of drawbacks. 
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[0007] One problem, aside from the ones listed above, is that these various 

technologies often have tight coupling to individual channels and systems, making 
adaptation to change progressively difficult. Development and maintenance of each new 
solution becomes increasingly expensive and time-consuming. 

[0008] Another problem with such systems is that new vendors encounter a steep 

learning curve when trying to interface with the various channels and systems. Also, end- 
to-end problem resolution between a vendor and a back-end office can be costly in time and 
resources. 

[0009] It was with the foregoing understanding that the present invention was made. 

SUMMARY OF THE INVENTION 

[00010] One object of the present invention is to provide a consistent mechanism for 

systems and applications (for example, vendor systems and applications) to access back-end 
functionality and data. 

[00011] Another object is to provide a mechanism for insulating applications from 

the various particular ways in which a service may be implemented. 

[00012] Another object is to abstract a back-end from vendor channels and to abstract 

middle-tier business applications from middle-tier infrastructure services. 

[00013] Another object is to provide a channel-driven model that enables multiple 

products to interface with a back office in a consistent and scalable manner. 

[00014] Another object is to provide a system wherein any application can be 

replaced without affecting back-end systems. 

[00015] Another object is to provide a system that enables single sign-on for a 

plurality of services. 

[00016] Another object is to provide a system that enables system-wide error 
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reporting. 



[00017] The above and other objects of the invention are realized by the 

embodiments described herein. 

[00018] A preferred embodiment of the subject invention comprises a system for 

implementing computer network services and applications, comprising a front-end 
component comprising one or more applications; a back-end component comprising one or 
more services; and an abstraction layer component operable to communicate with the front- 
end and back-end components. Embodiments also comprise such systems wherein the 
abstraction layer component is operable to provide de-coupling of services provided by the 
back-end component; the abstraction layer component is operable to provide de-coupling of 
applications in the front-end component; the abstraction layer component is operable to 
provide single sign on for substantially all of the applications; the abstraction layer 
component is operable to provide built-in entitlements; the abstraction layer component is 
operable to provide system wide error reporting; the abstraction layer component comprises 
a business integration component; abstraction layer component comprises a vendor 
connectivity component; the abstraction layer component comprises a security component; 
the abstraction layer component comprises a utility component; the abstraction layer 
component comprises a back end connectivity component; the abstraction layer component 
uses application templates to provide standardization of business services; the abstraction 
layer component is operable to provide one or more standardized interfaces to back end 
services; the abstraction layer component is operable to provide standardization of back end 
services; the abstraction layer component is operable to provide one or more standardized 
interfaces to external consumers and providers; and/or the abstraction layer component 
comprises a single deployment platform. 

[00019] In another preferred embodiment, the subject invention comprises a system 

for linking applications and services, comprising: a vendor connectivity component; a 
business integration component; a security component; a utility component; and a back end 
connectivity component. Embodiments also include such systems wherein: the vendor 
connectivity component is operable to standardize exposure of the applications to the 
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services; the vendor connectivity component is operable to provide a consistent abstraction 
between a user interface and a middle tier; the vendor connectivity component is operable 
to use standardized headers to provide substantially seamless system management 
integration between a caller and the applications; the vendor connectivity component is 
operable to provide automatically generated service entry points; the vendor connectivity 
component is operable to provide service location and activation capabilities using one or 
more standard interfaces; the one or more standard interfaces comprise a Universal 
Discovery Description and Integration interface; the business integration component is 
operable to provide call context information; the business integration component is operable 
to provide identity context information; the business integration component is operable to 
provide application context information; the security component is operable to provide 
distributed security; the security component is operable to provide single sign on; the 
security component is operable to provide entitlement management; the security component 
is operable to provide identity management; the utility component is operable to enable the 
applications to access utilities using a standardized application program interface; the utility 
component is operable to provide centralized end-to-end system management with an 
ability to correlate information across a plurality of parameters; the utility component is 
operable to enable auditing at system boundaries to manage service level agreements and 
method level metering; the back end connectivity component is operable to enable the 
applications to access the services via one standardized application program interface; the 
back end connectivity component is operable to provide access to back end data sources 
without changing a back end system; and/or the back end connectivity component is 
operable to enable de-coupling of the applications from the services. 



BRIEF DESCRIPTION OF THE DRAWINGS 



[00020] 



FIG. 1 is a general depiction of a preferred embodiment of the present 



invention. 



[00021] 



FIG. 2 depicts prior art, product-driven systems. 



[00022] 



FIG. 3 depicts a preferred channel-driven model. 
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[00023] FIG. 4 depicts prior art disadvantages. 

[00024] FIG. 5 depicts evolution of the need for the present invention. 

[00025] FIG. 6 illustrates use cases and data types supported by a preferred 
embodiment of the present invention. 

[00026] FIG. 7 depicts a preferred relationship between physical services, an 
abstraction layer, and framework interfaces. 

[00027] FIG. 8 depicts a preferred utility framework. 

[00028] FIG. 9 depicts a preferred back-end connectivity framework. 

[00029] FIG. 10 depicts a preferred security framework. 

[00030] FIG. 1 1 illustrates preferred internal and edge interfaces. 

[00031] FIG. 12 depicts exemplary components of a preferred embodiment. 

[00032] FIG. 13 depicts an exemplary implementation of a preferred embodiment. 

[00033] FIG. 14 illustrates a logon use case for a preferred embodiment of the 
present invention. 

[00034] FIG. 1 5 illustrates logical flow for security aspects of a preferred 
embodiment. 

[00035] FIG. 16 depicts a preferred Locate and Bind to Service scenario.. 

[00036] FIG. 17 depicts a preferred connectivity interface. 

[00037] FIG. 18 depicts a preferred error, audit, and trace management system. 

[00038] FIG. 19 depicts a preferred sequence diagram for a log system event. 



[00039] FIG. 20 illustrates exemplary interactions among preferred session 

management components. 



-5- 



1 -NY/1 754540.1 



[000401 


FIG. 21 depicts a preferred Add a User scenario. 


f 000411 


FIG. 22 depicts a preferred Login (Authentication) scenario. 


[000421 


FIG. 23 depicts a preferred Authorization for Target Resource scenario. 


[000431 


FIG. 24 depicts a preferred Change Role scenario. 


[00044] 


FIG. 25 depicts a preferred Logout scenario. 


[00045] 


FIG. 26 illustrates preferred interaction between a Business Integration 


Framework (BIF) and the Integration Framework, from .a BIF perspective. 


[00046] 


FIG. 27 depicts a preferred structural model of the BIF using Back End 


Connectivity. 




[00047] 


FIG. 28 depicts a preferred structural model of the BIF using the Utility 


Framework. 




[00048] 


FIG. 29 depicts a preferred behavioral model associated with a Funds 


Transfer application performing a Get Valid Accounts transaction. 


[00049] 


FIG. 30 depicts a preferred behavioral model associated with a Funds 


Transfer application performing a Get Bank Relationships transaction. 


[00050] 


FIG. 31 depicts a preferred behavioral model associated with a Funds 



Transfer application performing a Get Funds Transfer Options and Perform Funds Transfer 
transaction. 

[00051] FIG. 32 depicts a preferred behavioral model associated with a CAMU 

application performing a Validate and Lock Account transaction. 

[00052] FIG. 33 depicts a preferred behavioral model associated with a Mutual Funds 

application performing a Get Profile transaction. 

[00053] FIG. 34 depicts a preferred behavioral model associated with an Online 

Statements application performing a Get Statement List transaction. 
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[00054] FIG. 35 depicts a preferred behavioral model associated with an Online 

Statements application performing a Get Statements transaction. 

[00055] FIG. 36 depicts a preferred behavioral model associated with a List of Scans 

application performing a Get List of Lists transaction. 

[00056] FIG. 37 depicts a preferred behavioral model associated with a List of Scans 

application performing a Get Results transaction. 

[00057] FIG. 38 depicts a preferred behavioral model associated with a List of Scans 

application performing a Save Results transaction. 

[00058] FIG. 39 depicts a preferred behavioral model associated with a B2B 

Webservices application performing a Submit Trade transaction. 

[00059] FIG. 40 depicts a preferred behavioral model associated with a PCOE 

application performing a GetChecklnfo call. 

[00060] FIG. 41 depicts a preferred behavioral model associated with a PCOE 

application performing a ValidateCheckOrder call. 

[00061] FIG. 42 depicts a preferred behavioral model associated with a PCOE 

application performing a SubmitCheckOrder call. 

[00062] FIG. 43 depicts a preferred behavioral model associated with a Managed 

Assets application performing a Verify Account on Mainframe transaction. 

[00063] FIG. 44 depicts a preferred behavioral model associated with a Managed 

Assets application performing an Add Account to Client Account Collection transaction. 

[00064] FIG. 45 depicts a preferred behavioral model associated with a Benefits 

Online application performing multiple transactions. 

[00065] FIG. 46 is a flowchart diagram illustrating steps performed by a dynamic 

multi-step application. 
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[00066] 



FIG. 47 is an object diagram of a preferred 3270 Integration Framework. 



[00067] FIG. 48 is a use case diagram illustrating both single and multiple session 

scenarios. 

[00068] FIG. 49 depicts components of a preferred messaging integration framework. 

[00069] FIG. 50 is a sequence diagram for a preferred Locate and Bind to Service 

scenario. 

[00070] FIG. 51 illustrates a preferred use case for a back end connectivity interface 

framework. 

[00071] FIG. 52 illustrates a preferred Authorize and Create Command scenario. 

[00072] FIG. 53 illustrates a preferred Execute Command scenario. FIG. 43 depicts a 

preferred behavioral model associated with a Managed Assets application performing a 
Verify Account on Mainframe transaction. 

[00073] FIG. 54 illustrates a preferred messaging scenario, wherein the Integration 

Framework accepts messages from a data source and sends the messages to an external 
subscriber. 

[00074] FIG. 55 illustrates a preferred subscription scenario. FIG. 43 depicts a 

preferred behavioral model associated with a Managed Assets application performing a 
Verify Account on Mainframe transaction. 

[00075] FIG. 56 illustrates a preferred message delivery scenario. 

[00076] FIG. 57 depicts a preferred RPC logical interface definition. 



DESCRIPTION OF THE PREFERRED EMBODIMENTS 

[00077] Referring first to FIGS. 1-15, preferred embodiments of the present 

invention will now be described. It will be appreciated that the invention is equally 
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applicable without limitation for use in a number of other computer-related applications and 
systems. 

[00078] A preferred embodiment of the present invention relates to an Integration 

Framework (IF), which provides a consistent mechanism for systems to access backend 
functionality and data. IF preferably abstracts a backend from vendor channels and middle- 
tier business applications from the middle-tier infrastructure services, as shown in FIG. 1 . 

[00079] The IF preferably provides a mechanism to insulate applications from the 

many ways in which a service may be implemented, based not on who implements the 
services (vendor, back office, or other party) or how the services get implemented, but 
rather on what the requirements for the services are. In contrast to the prior art, EF-based 
business applications are simpler to develop, deploy, and manage. 

[00080] In one preferred embodiment, the invention comprises up to five major 

components that each provide substantially distinct functionality. Those components are: 
(1) a vendor connectivity framework; (2) a business integration framework; (3) a security 
framework; (4) a utility framework; and (5) a back-end connectivity framework. However, 
those skilled in the art will recognize that the IF is more general than the above five 
components and may compromise different combinations of those components or other 
components while still remaining within the scope of the invention. 

[00081] A preferred vendor connectivity framework provides one or more of the 

following benefits: (a) standardizes the way in which business services are exposed; (b) 
provides a consistent abstraction between a user interface and a middle tier; (c) provides 
seamless system management integration between callers and applications through 
standardized headers; (d) service entry points are auto -generated and hence kept up-to-date 
with the latest in web services standards (e.g., Global XML Web Services Architecture 
(GXA)) without any development effort; (e) provides service location and activation 
capabilities through standard Universal Discovery Description and Integration (UDDI) 
interfaces (thereby de-coupling the implementation from the service provider); (f) provides 
business service grouping and categorization guidelines; and (g) provides documentation 
and help on business services exposed by a back office. 
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[00082] Universal Discovery Description and Integration is a specification for 

distributed Web-based information registries of Web Services. UDDI is also a publicly 
accessible set of implementations of the specification that allow businesses to register 
information about the Web Services they offer so that other businesses can find them. 

[00083] A preferred business integration framework provides one or more of the 

following benefits: (a) common business application services; (b) provides call context 
(who called from which channel using what program and device); (c) provides identity 
context (end user and client information, preferably including identity, role and 
entitlements); and (d) provides application context information (for example, application 
level entitlements and state information) to applications. 

[00084] A preferred security framework (see FIG. 10) provides distributed security, 

which: (a) supports Web application and Web services; (b) provides a single sign-on that 
utilizes a corporate domain for internal users and establishes a Lightweight Directory 
Access Protocol (LDAP) directory for external users; (c) provides policy based security that 
enables externalization of access control rules from application code and eliminates the 
impact on an application when access rules change; and (d) provides enhanced context 
services that coordinate with an integrated framework context while enhancing entitlement 
response headers for applications. 

[00085] Preferably, the security framework also provides entitlement management, 

which: (a) establishes standards for role definition and role-based security, utilizing human 
resources (HR) data for classification of internal users and defining rules for classification 
of external users; and (b) provides a highly extensible model that allows integration and 
convergence of existing entitlement data and support for legacy entitlements. 

[00086] Preferably, the security framework also provides identity management, 

which: (a) provides an implemented meta-directory infrastructure to manage identity data; 
and (b) provides enhanced identity data integrity based on using an authoritative source for 
data. Single sign on is also provided in a preferred embodiment. 

[00087] A preferred utility framework (see FIG. 8) provides one or more of the 
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following benefits: (a) enables applications to access utilities via a standardized application 
program interface (API); (b) provides centralized end-to-end system management with an 
ability to correlate information across a number of parameters (e.g., user, application, 
environment, caller, calling device, and time); (c) enables auditing at system boundaries to 
manage service level agreements (SLs) and method level metering; (d) provides flexible 
convergence opportunities - changes in utilities have limited impact on applications; (e) 
reliability, availability, scalability and maintainability of applications and utilities is 
simplified - hotspots can be readily identified and addressed; (f) reduces cost of software, 
infrastructure and support; and (g) provides a standardized, optimized, and simplified state 
management solution. 

[00088] A preferred back-end connectivity framework (see FIG. 9) provides one or 

more of the following benefits: (a) applications access mainframe, distributed backend and 
third party data sources via the same standardized API; (b) provides consumption-based 
alternatives to applications (XML, bit-stream, MDAC, for example); (c) provides access to 
any backend data source without changing the backend system; (d) de-couples applications 
from backend systems; and (e) provides flexible convergence opportunities - changes in the 
backend have limited impact on applications or backend access services. 

[00089] Benefits of a preferred embodiment include: (1) standardizes business 

applications by using application templates; (2) standardizes interfaces to the services that 
support business applications; (3) standardizes the services themselves; (4) standardizes 
interfaces to external vendors; and (5) converges infrastructure by using a singular 
deployment platform. 

[00090] Other benefits include: (1) de-couples business applications from their 

supporting services, presentation tier, and other business applications; (2) streamlines the 
software release process; (3) reduces turnaround time on the software development life 
cycle (SDLC) as a whole; and (4) enhances operational manageability. 

[00091] One goal of IF was to move from a product-driven model that consisted of 

multiple products interfacing with a back office through their own integration, access, and 
security mechanisms (depicted in FIG. 2) to a channel-driven model that enables multiple 
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products to interface with a back office in a consistent and scalable manner (see FIG. 3). 

[00092] In prior art systems, front-end business applications often are integrated with 

back-office host and network-based applications through a complex and non-standard set of 
APIs, adapters and services (see FIG. 4). 

[00093] For example, as discussed above, multiple database-specific access methods 

may be required. There may be several ways to do the same thing. There may be no 
organized way to provide audit information, and diagnostics may be distributed throughout 
the environment (e.g., in event logs and text files). Regarding the back-end, there may be 
multiple vendor-supported middleware solutions in place, and there may be direct coupling 
of applications to an individual connectivity utility. Regarding security, there may be no 
single client authenticator allowing a user to interface with multiple applications, and there 
may be multiple entitlements systems. The security may be integrated with channel 
frameworks, and there may be inconsistent representation of processes and data. 

[00094] FIG. 5 depicts evolution of the need for the present invention. At first there 

was a layered architecture comprising a number of components to deliver specified 
services. Then business demand created a need to de-couple the front and back ends of the 
layered enterprise architecture. This led to the development of the IF using web services, 
which accommodate ubiquitous access to business services. 

[00095] Referring again to FIG. 1, it may be seen that the EF provides a "screen" 

behind which back end business applications and data can evolve over time. The IF's 
service oriented architecture (SOA) using web services provides a foundation for future 
elaborations of the enterprise architecture encompassing both the front and back end. 

[00096] FIG. 6 depicts exemplary use cases and application types supported by a 

preferred embodiment. 

[00097] FIG. 7 illustrates separation of framework interfaces and physical services 

provided by a preferred embodiment of the present invention. 

[00098] FIG. 1 1 illustrates exemplary internal and edge interfaces of a preferred 
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embodiment. Preferred IF interfaces provide an abstraction layer that protects vendors from 
changes to the services and the back office. Implementing business application facing 
interfaces (using, for example, Microsoft technologies) is familiar to developers, and 
significantly reduces migration burdens and associated costs and risks to schedules. The 
interfaces preferably provide a well-defined, standardized model for UI vendors and IF 
vendors to integrate with a back office. Edge interfaces (e.g., utility, vendor connectivity, 
and security interfaces) expose services to be used by vendors. Other interfaces (e.g., 
business integration and backend connectivity interfaces) expose services for IF developers 
to integrate IF and a back office. 

[00099] In an exemplary implementation (see FIG. 12), convergence is supported 

through development of a reference architecture for an IF. 

[000100] FIG. 13 shows an exemplary implementation of a preferred embodiment in 
greater detail. A preferred utility framework provides centralized end-to-end system 
management, supports an audit at system boundaries to manage SLs and method level 
metering, and provides an optimized and simplified state management solution. 

[000101] A preferred backend connectivity framework enables applications to access 
mainframe, distributed backend, and third party data sources via the same standardized API, 
and provides consumption based alternatives to applications (for example, XML, bit- 
stream, and Microsoft Data Access Components (MDAC)). 

[000102] A preferred security framework introduces a centralized security 
authorization solution; introduces centralized entitlement and role-based access control 
(RBAC) to enhance current access control lists (ACLs) and static maps and to enable 
multiple roles and role-switching; and enforces a unique identifier that is centrally 
implemented to link to identity maps. 

[000103] A preferred vendor connectivity framework standardizes the way in which 
business services are exposed; provides a consistent abstraction between the UI and middle 
tier; and enables service entry points to be auto-generated and hence kept up-to-date with 
latest standards. 
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[000104] A preferred business integration framework provides call context, identity 
context, and application context information to the applications. 



[000105] Referring again to FIG. 1, it may be seen that the IF standardizes services 
and infrastructure. For example, an API based thereon may be released and establish a 
standard set of services to be exposed to a UI vendor. 

[000106] The IF enables convergence of services and infrastructure. It provides a 
singular deployment platform; provides standardized interfaces to all services; converges on 
a standard for security services (for example, Netegrity) ; and converges data access points 
through a single data access point. 

[000107] The IF supports de-coupling. It enables de-coupling of business applications 
from their supporting services, de-coupling of business applications from business 
applications, and de-coupling of a presentation tier from business applications. 

[000108] The IF enables migration. Standard application types and application 
templates may be developed to simplify migration and streamline the release process 

[000109] The IF improves manageability. The IF utility services for error, log, and 
audit make it easier to locate problems and narrow down issues. Correlation is supported 
across services and applications 

[000110] FIG. 14 illustrates an exemplary use case: a logon use case. FIG. 14 is an 
interaction diagram showing steps of an exemplary logon process for a vendor seeking to 
logon to a particular service. 

[000111] FIG. 15 is a flow diagram showing logical flow for an exemplary initial 
session setup. 

[000112] FIGs. 16-57 and the following description illustrate specific details of 
exemplary embodiments of the present invention. These details are described solely for 
illustration and enablement, and are not intended to limit the scope of the claimed invention 
in any manner. 
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[000113] As discussed above, a preferred embodiment of the Integration Framework is 
focused on exposing a consistent set of interfaces to connect to back end functionality and 
data. It preferably consists of five major areas: Vendor Connectivity Framework, Security 
Framework, Business Integration Framework, Utility Framework, and Back End 
Connectivity Framework. 

[000114] The Utility Framework preferably provides one or more of the following 
services to the overall Integration Framework: 

[000115] (a) Specification Error, Audit, and Trace logging and querying interfaces for 
IF components. This provides standardization of error logging across IF. 

[000116] (b) System Management functionality to acquire, store, classify, and 
distribute application and infrastructure events such as errors and warnings. 

[000117] (c) Session Management functionality to provide state and context 
management for IF components. 

[000118] The Business Integration Framework (BIF) serves as an important part of a 
middle tier. A presentation tier, typically developed and hosted by outside vendors, 
communicates with backend systems through BIF. The input to BIF is folly authorized and 
partially authenticated by a security tier. BIF is responsible for enforcing business rules 
validation, transformation of data to backend (and conversely) to a common intermediate 
form that Back End Connectivity (BEC) can consume, and providing access for its 
applications to horizontal services such as logging, session management, etc. (these services 
themselves preferably are provided by the Utility Framework). 

[000119] BIF defines a vendor's interface to business applications as well as service 

providers of the Business Integration Framework. The BIF is somewhat analogous to COM 

objects for business purposes. The COM interface does not change because new 

functionality is implemented to fulfill the COM request. In the same manner, the Business 

Integration Framework is capable of defining just one interface for all application types, 

such that no matter what transaction is executed the interface remains the same; only the 

data passed by parameters changes. As a rule, code changes (even "module changes") 
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should not be required when a new application (of already existing app-type) is added to a 
suite of applications. 

[000120] Preferred Vendor Connectivity Framework Specification 
[000121] Exemplary Assumptions: 

[000122] (a) The vendor connectivity framework is the specification by which all core 
applications are located and executed. 

[000123] (b) The vendor connectivity framework is a specification of all the interfaces 
for the core applications being used. 

[000124] (c) The vendor connectivity framework is a specification for the context in 
which all core applications are activated. This includes the definition of the application 
request and response payload, as well as the definition of integration framework context 
outside the application request and response payload. 

[000125] Scenario Analysis 

[000126] A scenario relevant to Vendor Connectivity is Locate and Bind to Service. In 
this section the relevant sequence diagram is depicted for that scenario. 

[000127] Locate and Bind to Service. Precondition: The Vendor has passed all 
security checks, is authorized to execute a service, and all required logging of the request 
has taken place. See FIG. 16. 

[000128] Component Analysis 

[000129] This section outlines the Logical Interface Definition provided by Vendor 
Connectivity. Note that the interface is defined at the logical level and hence describes the 
behavior to be offered, but not the specific physical messages. Guidelines on how the 
physical messages can be constructed are given in the Implementation Considerations 
section below. 

[000130] Logical Interface Definition. As depicted in FIG. 17, the Vendor 

-16- 

1 -NY/1 754540.1 



Connectivity Component realizes the Connectivity interface. Note that a component could 
support multiple interfaces. 

[000131] The Connectivity interface preferably has the logical operations depicted in 
Table 1. 



TABLE 1 



Operation 


Parameters 


Return 


Behavior 


locateService 


serviceName 


List of matching 
service name 


Based upon the name of the 
service a matching list of 
appropriate service names 
are determined 


getServiceDescrip 
tion 


serviceName 


Service 

Descriptions 

(WSDL) 


The WSDL for the service is 
returned 


bindTo Service 


serviceDescrip 
tion 


Pointer to service 
to be executed 


The service is initiated and 
appropriate state is set up 



[000132] Implementation Considerations 

[000133] This section describes some of the considerations that preferably are taken 
into account while implementing the service. 

[000134] Protocol. These are the minimum requirements for the Vendor Connectivity 
Namespace. (Security/Context ID at the IF protocol level). 

[000135] Generic Header: 

ServicelD (leads to Service Category, Sub Cat, Access Point, Contact Info) 
Version 

DateTime (up to millisecond) 

ClientApp (Vendor app, test drivers etc.) 

Client User Info (to be ratified with security) 

Environment (Production, QA, PE, Development, Sandbox, UAT) 

EndPoint (FQ service end point - physical desc) 

[000136] Request: 

Service Specific Params 
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[000137] Response: 

Requested data: 
Requested status: 
Warnings: 

Error details: Error ID, Error type (server, app., etc.) 
Error Message, Source, Stack trace, Service call header 

[000138] General Interface Syntax 

[000139] Interface: <Verb><AppCategory>[Optional: 
Subcategory] [Optional:Qualifier](inSchema, outSchema) 

[000140] Generally speaking, in preferred embodiments, an interface represents an 
agreement between a consumer of a service or function and a provider of a service or 
function as to how the service or functionality should be invoked and used. This section 
describes the preferred general syntax of the service interfaces provided by the Integration 
Framework to vendors or internal consumers of services. The preferred syntax of the 
Integration Framework interfaces has a simple, predictable pattern, as follows: 

[000141] Interface: 

<Verb><AppCategory>[Optional:SubCategory][Optional:Qualifier](in, out) 

[000142] Verb: The action to be taken by the Integration Framework on behalf of a 
vendor application. For example, Query, Insert, Update, Delete, Publish, Subscribe. 

[000143] AppCategory: Represents a high-level category of business information, 
such as, Account, Research, Client, Order, MarketData. 

[000144] Subcategory: Represent a secondary level of business information, such as 
Holdings, Balances, Activity. When combined with a Verb and higher level AppCategory, 
serves to describe in more detail the nature of the request. For example, 
Query AccountHoldings. Subcategory is an optional descriptor. 

[000145] Qualifier: Describes a tertiary level of business information. Serves to 
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describe in more detail the nature of the action to be taken on behalf of vendor's 
application. Qualifier is an optional descriptor. For example, 
QueryAccountHoldingsMarketValue, where MarketValue represents a Qualifier. 

[000146] In: A self-describing data schema containing a list of input parameter 
names, parameter data types (e.g., integer, string, binary, etc. . .), and parameter values. 
Similar to an xml document with an attached xsd. 

[000147] Out: A self-describing data schema containing a list of output field names, 
data types (e.g., integer, string, binary, etc. . .), and output values. Similar to an xml 
document with an attached xsd. 



[000148] 


Examples of some possible interfaces: 


[000149] 


QueryAccountHoldingsMarket Value(in, out) 


[000150] 


QueryAccountActivity(in, out) 


[000151] 


QueryAccountAssetAllocation(in, out) 


[000152] 


UpdateClientInfoAddress(in, out) 


[000153] 


InsertOrderEquityEntry(in, out) 


[000154] 


List Connectivity Candidates are shown below in Table 2. 



TABLE 2 



Connectivity 
Approach 


Directory 


Standard 


Skills Required 


SOAP 


UDDI 


IETF 


Most major platforms 


COM+ 


ADSI 


Vendor 
Proprietary 


Microsoft platform specific 


RMI 


JNDI 


Java Proprietary 


Java platform specific 


Websphere/MQ 


JNDI 


Java Proprietary 


Java platform specific 


JMS 


JNDI 


Java Proprietary 


Java platform specific 


Tibco 


NA 


Vendor 


Vendor specific 
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Proprietary 





[000155] Service Provider Constraints 

[000156] Functional: The directory service preferably supports application 
partitioning. This allows for deployments of new versions of software to a small production 
test audience, before releasing the version to the general population. The directory service 
preferably allows for an individual application to be shut off on schedule or on demand. 



[000157] Non-Functional: Reliability, performance, and supportability. 
[000158] Preferred Utility Framework Specification 
[000159] Exemplary Assumptions 

[000160] A session will be established by the security framework component. For a 
given request being processed within the IF, a session ID may be obtained by querying a 
security framework interface. 

[000161] A session ID is an IF-wide unique identifier that will remain constant for the 
duration of a session. Security framework will provide an interface to validate the session 
ID. 

[000162] Storage for the state and context managed by the session management will 
be accessed by using the interfaces provided by the back-end connectivity framework. 

[000163] Access control for the state and context information managed by the session 
management will be expressed by using the interfaces supported by the security framework. 
The security framework will enforce the access control. 

[000164] Exemplary Design Goals for Error, Audit, and Trace System and System 
Management. 

[000165] An error is a common name for the status messages generated by an IF 
component to report its progress. These statuses may be informational, warnings, or errors. 

[000166] An Audit message is generated at each entry and exit point of a component. 
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Additional audit entries may be generated by a component to record significant progress in 
a component's activity. 



[000167] Tracing provides information for monitoring a component for debugging 
purpose. Tracing is disabled during normal functioning of a component. It can be enabled or 
disabled administratively. 

[000168] Single mechanism for producing audit events, reporting errors, and emitting 
trace events into system management facilities. 

[000169] Highly efficient, has minimal impact to the performance of the application. 

[000170] The viewer component provides a means to search and display events by 
type (Error, Trace, Audit) and/or customizable criteria (i.e. Account Number, Symbol, etc). 

[000171] Distributed administration of trace levels. 

[000172] Integrate errors from application components, network, and infrastructure 
into a common store to support information correlation. 

[000173] Exemplary Design Goals for Session Management 

[000174] Provide intra application state management. 

[000175] Provide inter application context management. 

[000176] Scenario Analysis 

[000177] FIG. 18 depicts a preferred Error, Audit, and Trace Management system and 
its interaction with the system management facility. The scenario in FIG. 1 8 also depicts 
scenarios applicable to the session management system. 

[000178] FIG. 19 depicts preferred interactions among components of an error, audit, 
and trace management system and system management facility components. FIG. 20 
depicts preferred interactions among session management components. 

[000179] Component Analysis 
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[000180] This section outlines a preferred Logical Interface Definition provided by a 
preferred Utility Framework. It should be noted that the interface is defined at the logical 
level and hence describes the prefered behavior to be offered, not the specific physical 
messages. 

[000181] The following are the functional descriptions of the common information 
structures refered to in the interface definitions. 

[000182] Common Information Structures: 

[000183] Raw Message: A Raw Message is an error, audit, or trace message 
generated by the message source in its native format. 

[000184] Message: A message is an error, audit, or trace message normalized by a 
message adapter. This standardization will decorate the message with information such as 
user ED, session ID, application ID, computer ID, and timestamp to make it usable for 
downstream processing. 

[000185] Criterion: A criterion is a collection of attribute values present in a 
normalized message structure. A set of criteria may be used to filter, search or order 
messages. 

[000186] Event Source Address: Event source address is an address to which an alert 
can be delivered. It may be an email address, a phone number, etc. 

[000187] Rule: A rule is a Boolean expression of criteria followed by an action to be 
taken in case the expression was evaluated to be true. 

[000188] Logical Interface Definition 



TABLE 3: Error, Audit, Trace Interfaces 



Operation 


Parameters 


Return 


Behavior 


WriteError 


Application ID 
Error ID 
Error Source 


None 


Gathers parameters 
and additional 
information such as 
session ID, time 
stamp, computer ID 
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Error Description 
Extra Information 




and sends the error 
to the system 
management 
adapter. 


WriteAuditlnformat 
ion 


Application!) 
Activity ID 
Audit Message 


Success/Failure 
Status 


Gathers parameters 
and additional 
information such as 
session ED, time 
stamp, computer ID 
and sends the error 
to the system 
management 
adapter. 


WriteTrace 


Application ID 
Trace Information 


None 


Gathers parameters 
and additional 
information such as 
session ID, time 
stamp, computer ID 
and sends the error 
to the system 
management 
adapter. 


[000189] Adapter - An Adapter acquires raw errors from application components, 
infrastructure, and vendors and converts them to a standard format for use by a system 
management facility. 

TABLE 4: System Management Interfaces 


Operation 


Parameters 


Return 


Behavior 


AddMessage 


Raw Message 


None 


Acquires a raw ' 
message from a j 
message source and 
formats it into a 
standard message 
format for use by 
system 
management. 



[000190] Rules Engine and Data Manager -. This component categorizes the messages 



and acts as a traffic cop between the messages and message stores. 



TABLES 
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Operation 


Parameters 


Return 


Behavior 


AddRule 


Rule 


Success/Failure 
Status 


Adds message 
categorization and 
correlation rules. 


PrioritizeRules 


Rule ID, Priority 


Success/Failure 


Sets the relative 
rules priority 


SetRuleProperties 


Rule ID, Property 


Success/Failure 


Enable/Disable Rule 



TABLE 6: Alerting Mechanism 



Operation 


Parameters 


Return 


Behavior 


Subscribe 


Criteria 

Subscriber Address 


Success/Failure 


Creates a 

subscription for an 
alert for a message 
matching the given 
criteria. 


Unsubscribe 


Criteria 

Subscriber Address 


Success/Failure 


Removes a 
subscription. 


ListSubscriptions 


[Criteria] 


List of 
Subscriptions 


Lists subscriptions 
matching the 
criteria. 



TABLE 7: Viewing System Management Messages 



Operation 


Parameters 


Return 


Behavior 


Search 


Criteria 


Messages 


Searches and 
retrieves messages 
matching the 
criteria 


Filter 


Messages 
Criteria 


Messages 


Filters a set of 
messages based on 
the criteria 


Consolidate 


Messages 
Criteria 


Messages 


Consolidates 
messages based on a 
given criteria 
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TABLE 8: Session Management Interfaces 



Operation 


Parameters 


Return 


Behavior 


SetState 

0 


Session ID 
State ID 
Value 


Success/Failure 


Saves the state 
information 


GetState 


SessionID 
State ID 


Value 


Retrieves the state 
information 



[000191] Preferred Security Framework Specification 
[000192] Exemplary Assumptions 

[000193] The Security Framework is the specification by which all core applications 
are protected; and by which all requests to core applications are authenticated and 
authorized. 

[000194] The Security Framework is a specification of all the interfaces for the 
distributed security services that wrap the core applications being used. 

[000195] The Security Framework is the specification for all user data (defined 
separately from application data). 

[000196] The Security Framework is the specification for Role-Based access control. 

[000197] The Security Framework supports Role inheritance and delegation. 

[000198] All calls made to the Security Framework will be logged based on defined 
corporate policies. 

[000199] The Security Framework is the specification for issuance on session 
information. 

[000200] Security Frame Work will adhere to the information security standards as 
defined by corporate policies. 
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[000201] Scenario Analysis 



[000202] The scenarios that are relevant to a preferred Security Framework are listed 
below. The relevant sequence diagrams are depicted for the scenarios. For the use cases that 
follow the Login Use Case, the user is assumed to hold a valid authentication token. 

[000203] Add User. Precondition: All approvals have been obtained. See FIG. 21. 

[000204] Login (Authentication). Precondition: User has already been provisioned. 
See FIG. 22. 

[000205] Authorization for Target Resource. Precondition: User has already logged- 
in and has AuthToken. See FIG. 23. 

[000206] Change Role. See FIG. 24. 

[000207] Logout See FIG. 25. 

[000208] Component Analysis 

[000209] This section outlines a preferred Logical Interface Definition provided by 
Security Framework. Note that the interface is defined at the logical level and hence 
describes the behavior to be offered, but not the specific physical messages. Guidelines on 
how the physical messages can be constructed are given in the Implementation 
Considerations section. 

[000210] Logical Interface Definition: the Security Framework component preferably 
realizes the following interfaces (note that a component could support multiple interfaces): 
Provisioning; IdentityManagement; EntitlementManagement; and AccessControl. 

[000211] The Provisioning Interface has the GetUserConfigurationQ logical 
operation/method and the AccessControl interface has the rest of the following logical 
operations/methods: 

TABLE 9 



Operation 


Parameters 


Return 


Behavior 
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Operation 


Parameters 


Return 


Behavior 


GetUserConfiguration 


UniqueUseiTD 


UserConfigurationData 


Returns 
configuration 
details for the user 
so that the Vendor 
can provision the 
user on their side. 

Must be an 
authenticated bind 
to Security 
Framework 


Authenticate 


Security 
Assertions 

[Must include 
UniqueUserld 
plus a trusted 
token that verifies 
that user has been 
authenticated on 
the Vendor side] 


MLAuthToken 


Authenticates the 
user to the realm 
based on the user's 
successful 
authentication to 
the Vendor 
security realm 


GetRoleMap 


UniqueUserld- 
[Unique Id for 
user as 

recognized within 
systems-<string>] 

PlatformName 
[Platform like 
TGA, MLD 5 B01 
etc so that the 

rp1 pvant rnlfi^ for 

that platform can 
be returned] 


List of roles user 
belongs to 


Returns list of 
roles that the User 
can play within the 
realm. Vendor 
needs to provide 
UI for user to 
switch roles. 

Must be an 
authenticated bind 
to Security 
Framework 


SetRole 


UniqueUserld- 
[Unique Id for 
user as 

recognized within 
systems-<string>] 

RoleName 
[Identifier for the 
role that user 


Context Info for that 
role 


Returns associated 
context/entitlement 
info for that role. 

Must be an 
authenticated bind 
to Security 
Framework 
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Operation 


Parameters 


Return 


Behavior 




wants to play] 






Logout 


UniqueUserld- 
[Unique Id for 
user as 

recognized within 
systems-<string>] 


Status message, 
Revoke AuthToken. 


Resets 

authentication 
tokens and returns 
status message. 

Must be an 
authenticated bind 
to Security 
Framework 


TABLE 10: Vendor Implemented Methods 


Operation 


Parameters 


Return 


Behavior 


AddUser 


UniqueUserED 


Acknowledgement 


Accepts a request 
for provisioning a 
new user and 
returns an 
acknowledgement 


SetContext 


Contextlnfo 


Acknowledgement 


Updates context 
info for user for 
current role 



[000212] Implementation Considerations 



[000213] This section describes some of the considerations that preferably are taken 
into account while implementing the service. 

[000214] Protocol. General Interface Syntax: 

Interface: <Verb><AppCategory>[Optional: Subcategory] [Optional: Qualifier] 

Verb: Add, Update, Delete, Get, Authenticate, Authorize 

AppCategories: User, Role, Identity 

Subcategory: Map 

Qualifier 

[000215] Example: AddUser, GetRoleMap, AuthenticateUser etc. 
[000216] Service Provider Constraints . 
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[000217] Functional Constraints. The Security Framework preferably provides the 
following functionality and supports the following scenarios: 



[000218] (A) The concept of multiple roles and allowing users to switch roles. 

[000219] (B) The concept of identity mapping so a user can be identified across 
multiple systems. 

[000220] (C) Seamless authentication of a user coming from a trusted vendor's 
security realm. 

[000221] (D) Third Parties should have access to accounts based on permissions set 
by the account owner. 

[000222] (E) Delegation of access permissions should be supported. 

[000223] (F) An access control mechanism is provided to check an individuals' 
entitlements to determine whether the permission to access a particular service has been 
turned on. 

[000224] (G) Permissions will be granular to control access to a service, interface, or 
method. 

[000225] (H) Access Control prevents access to actions in a service before that action 
is invoked (i.e., the front-end prevents a client from placing an Options trade if the service 
has not been turned on because the documentation has not been received). 

[000226] (I) Centralized security management is provided to ensure consistency 
across all web services and with the Back-end. 

[000227] (J) Single sign-on to all business services including online channels. 
[000228] (K) Global logout and site specific logout capabilities. 
[000229] (L) Interfaces for administration and reporting. 

[000230] (M) Establish, validate, and cancel a session token associated with an 
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authenticated session. 



[000231] (N) Store and expose user entitlements and user profile information. 

[000232] The Vendor is expected to provide an interface to support provisioning of 
new users. The interface should implement the method AddUser(. . .). The vendor also is 
expected to provide an interface to support updating user context for users. The interface 
should implement the method SetContext(. . .). 

[000233] Preferred Business Integration Framework Specification 
[000234] Exemplary Design Goals for Business Integration Framework 
[000235] To provide clean application abstractions. 

[000236] Disallow coupling between Ul/Presentation zone and Fulfillment/Host zone. 

[000237] Identify common services that all applications need (e.g., logging). 

[000238] Determine application types and corresponding characteristics. 

[000239] Define "Application model" which includes data model, design model, 
configuration model, deployment model, etc. 

[000240] Exemplary Assumptions 

[000241] BIF abstracts common behavior among application types, identified by the 
use cases. 

[000242] BEF exposes common services like utility framework services, backend 
connectivity framework services, etc., to the business services. 

[000243] BIF enables adding a new application of a known application type without 
any changes to the common abstractions. 

[000244] BIF assumes that the Integration Framework provides for central access to 
session data and shared access to central data. The integrity of the session data must be 
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protected at all times. 

[000245] By the time a request comes to BIF, security has fully authenticated the 
request. In one embodiment, authorization is done as part of an SEC filter before it reaches 
the BIF. 

[000246] Scenario Analysis at BEF and Peer Level 

[000247] FIG. 26 depicts a preferred Business Integration Framework and its 
interaction with the Integration Framework from a BIF perspective. 

[000248] FIG. 27 shows a preferred structural model of BIF usage of Back End 
Connectivity. 

[000249] A preferred structural relationship of BIF usage of the Utility Framework 
components is depicted in FIG. 28. 

[000250] Exemplary Sequence Diagrams: As detailed in Table 1 1 below, a number of 
current applications have been analyzed and documented as sequence diagrams. 



TABLE 11 



Application Type 


Application 


Transaction 


Execute Synchronous Request 


Funds Transfer 


Get Valid Accounts 


Execute Synchronous Request 


Funds Transfer 


Get Bank Relationships 


Execute Synchronous Request 


Funds Transfer 


Get Funds Transfer Options 
and Perform Funds Transfer 


Dynamic Multi-Step 


CAMU 


Validate and Lock Account 


Multi-Step Static 


Mutual Funds 
Profile 


Get Profile 


Execute Synchronous Request 


Online Statements 


Get Statement List 


Bulk Data Transfer Request 


Online Statements 


Get Statement 


Execute Synchronous Request 


List of Scans 


Get List of Lists 


Execute Synchronous Request 


List of Scans 


Get Results 


Execute Synchronous Request 


List of Scans 


Save Results 


Execute Synchronous Request 


B2B Webservices 


Submit Trade 
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Execute Synchronous Request 


Online Deal 
A4anaj?ement 


Search for client 


Execute Synchronous Request 


Online Deal 
Nfanaffement 


Select Client 


Execute Synchronous Request 


Online Deal 
Management 


Submit Indication of Interest 


T^YPciifp S vnrhrnnnii<; Rpnne^t 


Ruhicon 

JLVUL/lVVll 


Subscribe 


A^vnfVhrnrioii<\ T^Jotifl nation 
Request 


Rubicon 


Set up alert 


Publish Vendor Notification 


Rubicon 


Alert Triggered 


Execute Synchronous Request 


PCOE 


GetChecklnfo 


Execute Synchronous Request 


PCOE 


ValidateCheckOrder 


Execute Synchronous Request 


PCOE 


SubmitCheckOrder 


Execute Synchronous Request 


Managed Assets 


Verify Acct On MainFrame 


Execute Synchronous Request 


Managed Assets 


Add Account To Client Acct 
Collection 


Multisten 


MLX Allocation 


Block Allocation 


Multistep/ Execute Synchronous 
Request 


Benefits Online 


Multiple 



[000251] FIGS. 29-45 depict exemplary sequence diagrams for applications 

and transactions detailed in Table 11. 

[000252] FIG. 29 depicts a behavioral model associated with a Funds Transfer 

application performing a Get Valid Accounts transaction. 

[000253] FIG. 30 depicts a behavioral model associated with a Funds Transfer 

application performing a Get Bank Relationships transaction. 

[000254] FIG. 31 depicts a behavioral model associated with a Funds Transfer 

application performing a Get Funds Transfer Options and Perform Funds Transfer 
transaction. 

[000255] FIG. 32 depicts a behavioral model associated with a CAMU 

application performing a Validate and Lock Account transaction. 
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[000256] FIG. 33 depicts a behavioral model associated with a Mutual Funds 

Profile application performing a Get Profile transaction. 



[000257] FIG. 34 depicts a behavioral model associated with an Online 

Statements application performing a Get Statement List transaction. 

[000258] FIG. 35 depicts a behavioral model associated with an Online 

Statements application performing a Get Statement transaction. 

[000259] FIG. 36 depicts a behavioral model associated with a List of Scans 

application performing a Get List of Lists transaction. 

[000260] FIG. 37 depicts a behavioral model associated with a List of Scans 

application performing a Get Results transaction. 

[000261] FIG. 38 depicts a behavioral model associated with a List of Scans 

application performing a Get Results transaction. 

[000262] FIG. 39 depicts a behavioral model associated with a B2B 

Webservices application performing a Submit Trade transaction. 

[000263] FIG. 40 depicts a behavioral model associated with a PCOE 

application performing a GetChecklnfo call. 

[000264] FIG. 41 depicts a behavioral model associated with a PCOE 

application performing a ValidateCheckOrder call. 

[000265] FIG. 42 depicts a behavioral model associated with PCOE 

application performing a SubmitCheckOrder call. 

[000266] FIG. 43 depicts a behavioral model associated with a Managed 

Assets application performing a Verify Account on Mainframe transaction. 

[000267] FIG. 44 depicts a behavioral model associated with a Managed 

Assets application performing an Add Account to Client Account Collection transaction. 
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[000268] FIG. 45 depicts a behavioral model associated with a Benefits Online 

application performing multiple transactions. 

[000269] Component Analysis: Interfaces to BIF 

[000270] Interfaces of a candidate application to BIF API: 
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TABLE 12 


Use Case Types (App 
Types) 


Parameters 




Comment 


Operation Header 


Payload 


Multi Step (dynamic) 


See FIG. 46 (flowchart 
diagram illustrating a 
dynamic multi-step 
application). 


BIFML Header 
consisting of 
ContextHeader and 
CallHeader (see 
below for the XML 
schema) 


BIFML 
payload 
consisting of 
APPdata, 
RuleData, 
SessionData, 
DownloadData 
. ErrorData 


Multi Step (static) 


A table mapping App 
calls to Validate, 
Ancillary and Submit. 


BIFML Header 
consisting of 
ContextHeader and 
CallHeader (see 
below for the XML 

JVl 1^1 lid 1 


BIFML 

payload 

consisting of 

APPdata, 

RuleData, 

Sle^ionData 

k_J vOOlvlll- J CI LCI, 

DownloadData 
. ErrorData 


Single Step 


Single step is a special 

pqcp r\*f mill ti ctf^f* 
vaoC Ul 111 111 11 olCJJ Willi 

only one step to 
execute. 






Bulk Transfer 


Same as single step 
with specification to 
BEC to allow high- 
bandwidth transport. 






Execute Synchronous 
Request 


Same as Single Sten 






i\.jy i i v/i 11 Kji lkj uo 

Notification and 
Asynchronous request 
(originated by BIF 
client) 


Same as single step 
with a spec to BIF for 
guaranteed delivery. 
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[000271] 



Component Analysis: BIF to BIF Service Provider: 



TABLE 13 



Operation 


Operation Header 


Payload 


Execute 


BLFML Header consisting of 
ContextHeader and CallHeader 


BLFML payload consisting of 
APPdata, RuleData, SessionData, 
DownloadData. ErrorData 



[000272] <BIFMLJVIessage> 

<BIFML_Header/> 
<BIFMLPayload/> 

</BIFML_Message> 
<BIFML_Header> 

<BIFML_Context_Header/> 
<BIFML_Call_HEADEPv/> 
</BIFML_Header> 
<BEFML_Message> 

<BIFML_Header> 

<BIFML_Context_Header> 
<Product /> 
<Channel /> 
<Touchpoint /> 
<Operation /> 
<Mode /> 

<ExecutionContextED /> 

<RequestId /> 

<BEFParameterList> 
<BEFParameter /> 
</BIFParameterList> 
</BIFML_Context_Header> 
<BIFML_Call_HEADER> 

<SERVICEID /> 

<VERSION /> 

<DATETIME /> 

<CLIENTAPP /> 

<CLIENTUSERINFO /> 

<ENVIRONMENT /> 

<ENDPOINT /> 

</BIFML_Call_HEADER> 

</BIFML_Header> 

<BIFMLPayload> 
<APPLICATION_DATA /> 
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<SESSION_DATA /> 
<RULE_Data /> 
<DOWNLOAD_DATA /> 
<ERROR_DATA /> 
</BEFMLPayload> 
</BIFML_Message> 

[000273] Component Analysis: Preferred BIF to Backend Connectivity Interfaces 

[000274] Interfaces to Backend Connectivity: Note that even though the below 
exemplary requirement on Back End Connectivity is expressed in an interface format, this 
description does not define interfaces that BEC must expose, it merely uses this notation as 
a vehicle to express the requirements. 

[000275] There are primarily three main preferred operations to BEC: SendReceive, 
SendOnly, and ReceiveOnly. SendOnly works as the main vehicle for asynchronous 
communication to BEC; ReceiveOnly works as the main vehicle for asynchronous 
communication from BEC; and SendReceive is the communication vehicle for synchronous 
calls. 



TABLE 14 



Operation 


Behavior 


Parameters 






Global Header 
Info 


Operation Header 


Payload 


Send 
Received 


Sends the 
information 
and block 
waits for the 
result. The 
backend 
executes and 
returns the 
answer. 


Number Of 
Operations Global 
Input Data Length 
Execution Context 
Id Global Output 
Data Length Return 
Error Code 


Operation Code 
Product Code 
Channel Code 
Touch point Code 
Operation Version 
Number 

Operation Input Data 
Length 

Operation Output 
Data Length 


Send Receive 
Payload 

(Specific to 
App) 
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SendOnly 


Sends the 
message and 
gets ACK. 


Number Of 
Operations Global 
Input Data Length 
Execution Context 
Id Global Output 
Data Length Return 
Error Code 
Acknowledgement 
Number Subscriber 
App Id Subscriber 
App Group Id 


Operation Code 
Product Code 
Channel Code 
Touch point Code 
Operation Version 
Number Operation 
Input Data Length 
Operation Output 
Data Length 


Send Payload 
XML 

(Specific to 
App) 


Receive 
Only 


Asynch- 
ronously 
receives the 
message 


Number Of 
Operations Global 
Input Data Length 

Execution Context 
Id 

Global Output Data 
Length 

Return Error Code 

Acknowledgement 
Number 

Target Subscriber 
App Id 

Target Subscriber 
App Group Id 


Operation Code 

Product Code 

Channel Code 

Touch point Code 

Operation Version 
Number 

Operation Input Data 
Length 

Operation Output 
Data Length 


Receive 
Payload 

(specific to 
App) 



[000276] SL for BEC: Key preferred SL requirements for BEC are the following: 



[000277] (A) Adding a new Backend Call for an application does not result in 
changing BEF code. 

[000278] (B) BEC supports Dynamic Transport Selection at Runtime. It also allows 
for failover to an alternate transport mechanism, in case the primary mechanism fails. 

[000279] To support the above SL, the applications within BIF define the following 
two types of parametric data. 

[000280] Transport Type Specification: This specifies the transport protocol to be 
used for each call initiated by the BIF Client, if that call includes usage of BEC. 
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TABLE 15: Example of Transport Type Document (for FTS application) 



Calls 


Description 


Transport Type (Example) 


Calll 


Get Valid Accounts 


ECI 


Call2 


Get Bank Relationships 


ECI 


Call3 


Funds Transfer Options 


ECI 



[000281] Transport Failover Specification: This specifies failover strategy for the 
transport protocols on a per call basis. 

TABLE 16: Example of Transport Failover Document (for FTS application) 



Calls 


Description 


Primary 

Transport 

(Example) 


Failover 

Transport 

(Example) 


Failover Condition 


Calll 


Get valid 
Accounts 


ECI 


MQ 


if PrimaryTransport.Timeout = 

true 

and 

<PrimaryTransport>.Waittime 
> <ReferenceData>.MaxTime 


Call2 


Get Bank 
Relationships 


ECI 


MQ 


if 

<PrimaryTarget>.NumOfTries 

> 

<ReferenceData>.NumOfTries 


Call3 


Funds Transfer 
Options 


ECI 


MQ 


if 

<PrimaryTarget>.NumOfTries 

> 

<ReferenceData>.NumOfTries 



[000282] 



Component Analysis Preferred: BIF to UTIL interfaces 



[000283] Note that even though the below requirement on the Utility Framework is 
expressed in an interface format, this description does not seek to define the interfaces that 
the Utility Framework should expose; it merely uses this notation as a vehicle to express the 
requirements. 

TABLE 17: Interfaces to UF - InterApp Context Manager 



Operation 



Parameter 



Behavior 
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Get 


Groupld 

Applicationld 

UserSessionld 

Datald 

DataXML 


The application retrieves the context 
using Get. The context data is 
returned in DataXML output 
variable.UF Validates if the 
application is allowed to retrieve the 
context within its Group. 


Set 


Groupld 

Applicationld 

UserSessionld 

Datald 

DataXML 


The application Sets the context using 
Set. UF Validates if the application is 
allowed to set the context within it's 
Group. 


TABLE 18: Interfaces to UF - IntraApp Context Manager 


Operation 


Parameter 


Behavior 


Get 


Applicationld 
UserSessionld 
Datald 
DataXML 


The application retrieves the context 
using Get. The context data is 
returned in DataXML output 
variable. 


Set 


Applicationld 
UserSessionld 
Datald 
DataXML 


The application Sets the context using 
Set. 


TABLE 19: Interfaces to UF - Error Logging 


Operation 


Parameter 


Behavior 


WriteErrorEve 
nt 


EventSource{ Applicationld, 
Workerld } 

Correlationld 

ErrorNumber 

ErrorMessage 

Status 


The application uses this operation to 
write an error event to UF. 
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WriteWarning 
Event 


EventSource{ Applicationld, 
Workerld } 

Correlationld 

Message 

Status 


The application uses this operation to 
write a warning event to UF. 


WritelnfoEvent 


EventSource{ Applicationld, 
Workerld } 

Correlationld 

Message 

Status 


The application uses this operation to 
write an info event to UF. 


TABLE 20: Interfaces to UF - Tracing 


Operation 


Parameter 


Behavior 


WritelnvokeBe 
ginEvent 


EventSource{ Applicationld, 
Workerld} 

Correlationld 

Input 

Status 


The application uses this operation to 
write a trace event to UF. This trace 
is used at the start of a function body. 


WritelnvokeEn 
dEvent 


EventSource{ Applicationld, 
Workerld} 

Correlationld 

Output 

RequestCriteria 
Status 


The application uses this operation to 
write a warning event to UF. This 
trace event is used at the end of a 
function body. 



[000284] Implementation Considerations 



[000285] This section describes some of the considerations that should be taken into 
account while implementing the service. 

[000286] Exemplary Design Goals for Business Integration Framework: 
[000287] (A) To provide clean application abstractions. 

[000288] (B) Disallow coupling between Ul/Presentation zone and Fulfillment/Host 
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zone. 



[000289] (C) Identify common services that all applications need (e.g., logging, etc). 

[000290] (D) Determine application types and corresponding characteristics. 

[000291] (E) Define "Application model" that includes data model, design model, 
configuration model, deployment model, etc. 

[000292] Preferred Backend Connectivity Framework Specification 
[000293] Scope of Framework 

[000294] The BEC Framework preferably has three primary components: 3270 
Integration Framework, RPC Framework, and Messaging Framework. 

[000295] Scope of 3270 Framework: The 3270 Framework is focused on exposing a 
consistent set of interfaces to connect to Back End functionality and data. It preferably 
comprises the following major components (see FIG. 47): 

[000296] (1) Business Object (BO) layer that comprises a 3270 Connectivity Adapter 
and other IF Services (e.g., Security Svc and Utility Svc). The 3270 Adapter preferably 
interacts with the host and provides features like caching of transactions and terminal 
pooling with the help of a Utility Framework. A cross-reference table of transactions 
(maintained in this layer) and their corresponding relevant quirks is accessed by the Adapter 
to get transaction specific customization (e.g., Cache / Not to Cache, Formatted/Not 
Formatted**), a pool of sessions that the transaction can use, and a description of the 
transaction. 

[000297] (2) A Data Object (DO) layer that executes the corresponding program in 
the host. 

[000298] (3) The Rendering Object (RO) layer is the requester responsible for 
transforming the resultant data stream from the BEC IF into a presentation format and 
displaying it on the rendering device, or consuming the Datastream for ScreenScraping. 
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[000299] ** Many applications adhere to a presentation format (i.e., the first line 
comprises a FUNCTION, SELECT and PWD field, followed by the Application content, 
and the last line is the Action field). The Formatted/un- formatted information usually is 
necessary to create the initial map for the mainframe. 

[000300] The high-level object diagram depicted in FIG. 47 can be applied to the 
following two scenarios: 

[000301] (1) Single Session Scenario: The requester "explicitly" passes the last 
character of the TermID (the 3270 Adapter will extract the seed from the context of the 
requester) as part of the payload to the BEC IF. Looking at the payload, the 3270 Adapter 
examines the requirement of a single session user and does not involve a Utility Framework 
for Terminal pooling. However, it does involve the Utility Framework for caching* the 
transaction (the resultant DataStream), the screen map and storing/retrieving contextual 
information like terminal token. 

[000302] (2) Multiple Session Scenario: A user needs the 3270 Adapter to perform 
the task of deciding what terminal the request should be executed on (there is no explicit 
mention of the last character of the TermID in the payload). The 3270 Adapter maintains a 
set of used terminals in the session state (with the help of State Management of the Utility 
Framework). Caching* transactions is also part of this scenario. 

[000303] *The purpose of caching transactions is to increase performance of 3270 
access. It avoids round-trips to the mainframe for transactions that have already been 
executed. The cached copy has an expiration value that ensures that the user does not get 
stale information. 

[000304] FIG. 48 illustrates both Single and Multiple Session preferred scenarios. 

[000305] Scope of RPC Framework: The goal of a preferred Remote Procedure Call 

(RPC, or Programmatic Interface) Framework is to provide a uniform interface to all back 

end systems regardless of the underlying technology or protocol. The scope of technologies 

the interface must support includes, but is not limited to: host data and process; access to 

database systems such as SQL Server, Oracle, and Sybase; and third-party sources such as 
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Standard & Poor's and New River. As with the other frameworks, the interface provided 
preferably is based on adapter techniques. Transactions, while supported by the underlying 
technologies, preferably are not addressed by this framework. 

[000306] Scope of Messaging Framework: The Messaging Integration Framework 
preferably defines a consistent set of interfaces for message consumers and message 
producers to exchange messages. It allows guaranteed distribution of addressed messages 
with defined message type from message producers to message consumers. The Messaging 
Framework distributes two types of messages, namely Host Print and Host Alert, from a 
central site to local branch offices. It consists of six major components (see FIG. 49): 

[000307] Adapter 4910 provides technical interfaces to various different data sources. 
It accepts messages from data sources and performs message/protocol transformation to 
generate a common message format as an input to Addressor. 

[000308] Addressor 4920 is responsible for message addressing, enforcing business 
rules, and transforming the output messages into the format that can be consumed by 
message consumers. 

[000309] Publisher 4930 is an interface object used by the Addressor to send 
"addressed" messages to the Pub/Sub Server for distribution. 

[000310] Subscriber 4940 is an interface object used by message consumers to 
connect to the Integration Framework Pub/Sub Server and receive messages. 

[000311] The Publish-and-Subscribe Messaging System 4950 distributes messages to 
consumers. 

[000312] Adapter Controller 4960 is a daemon service used to initialize, manage, and 
monitor adapters. 

[000313] The following exemplary assumptions may be made regarding the 
frameworks. 



[000314] RPC Framework Assumptions: 
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[000315] (1) The total cost of ownership (TCO) of the framework must be considered 
in all decisions regarding its specification. 

[000316] (2) The framework for back end connectivity should provide the minimum 
gap possible from existing back end applications. Existing back end applications should 
ideally be exposed to the framework with no changes to the application. 

[000317] (3) The framework solution must meet the minimum requirements of all 
applications. Conversely, all applications must use the framework solution. 

[000318] (4) Industry standard APIs and protocols will be used. 

[000319] (i) When both a vended solution and an in-house solution exist and meet the 
minimum requirements, prefer the vended solution. 

[000320] (ii) Transactions are considered out of scope for the framework. This means 
that the Back End Connectivity Framework will not support resource locking mechanisms 
and will not participate in two-phase commits. This, however, does not prevent back end 
applications from participating in transactions themselves. 

[000321] (iii) Applications using the framework must maintain transaction volume 
levels and SL consistent with existing requirements. 

[000322] (iv) This description describes a preferred embodiment. The description 
describes one set of interfaces for the framework. It is assumed that there may be many 
service implementers of the interface. 

[000323] 3270 Framework Exemplary Assumptions: 

[000324] (1) The Authorization process will be taken care of by Security. 

[000325] (2) The Authorization process will make use of a utility service to set 
credentials. The 3270 Connectivity Service will use the utility service to retrieve it. 

[000326] (i) The TermID Token state can be set and retrieved with the help of utility 
services. 
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[000327] (ii) The 3270 Connectivity Service will use the utility service for Audit, 
Error Tracing, and Logging. 

[000328] (iii) Application relevant state (e.g., Account#, Symbol, FC#, etc.) will be 
pre-filled into the response screen by the vendor. 

[000329] (iv) Vendor takes care of transforming the Standardized Data returned by the 
BEC EF into a presentation format. 

[000330] (v) Vendor will map the attributes of the resultant fields to the presentation 
appropriately (see Appendix A). 

[000331] Messaging Framework Exemplary Assumptions: 

[000332] (1) The Authorization/ Authentication process will be taken care of by the 
Security framework. 

[000333] (2) Consumers will be connected to a private network, so no message 
encryption is required. 

[000334] (3) Branch-level subscription. If user is not at workstation, user does not get 
alerts. 

[000335] (4) Business rules such as failure retry, inbox management, and courtesy 
copy for alert messages will be provided by the BIF. 

[000336] (5) Message addressing interface will be provided by the Security 
Framework. 

[000337] (6) Identity mapping will be done by the Security Framework. 

[000338] (7) Error logging, Tracing, and Auditing will be provided by the Utility 
Framework. 

[000339] (8) Local alerts, price limits alerts, and the availability of email alerts will be 
provided by vendors. 
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[000340] Scenario Analysis 



[000341] 3270 Scenario Analysis. A scenario relevant to the Vendor Connectivity is 
Locate and Bind to Service. The relevant sequence diagram for that scenario is depicted in 
FIG. 50. 

[000342] Locate and Bind to Service: Precondition: User has been provisioned and 
logged in and has an authorization token from Security. 

[000343] Once authorized, the 3270 Adapter picks up the credentials from the 
Envelope/Call Context of the request and executes the transaction. 

[000344] RPC Scenario Analysis. The analysis begins with defining the use cases. 
The use case for the back end connectivity programmatic interface framework is depicted in 
FIG. 5 1 . There are two actors important to the framework: the application requiring back 
end services, and the back end system providing the services. The remaining actors provide 
support for security, service discovery, and logging. 

[000345] There are two distinct scenarios that can be developed for back end 
connectivity RPC. The first is authorizing the activity and finding the provider of the 
service. The second is execution of the service. In this section those scenarios are 
discussed and relevant sequence diagrams are described. 

[000346] As mentioned in the assumptions, in this embodiment the back end 
connectivity framework does not support transactional processing. However, each of these 
scenarios may itself represent a transaction. 

[000347] Authorize and Create Command. This scenario represents the activities 
typical to an application requesting a command resource. The request contains the name of 
the requested resource, the user context, and the desired service level (SL). The SL can be 
used when more than one service is available for the requested resource. 

[000348] This scenario can be viewed as a novel adaptation of the classic Class 

Factory Pattern. In that pattern, rather than applications creating instances of a particular 

implementation, the factory object creates instances on behalf of the caller. In this scenario, 
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the Command Manager acts as a factory taking requests for command instances. In order to 
do that the Command Manager must first ask the Security Framework whether the 
command is authorized for the current user context. After authorization, the Command 
Manager uses the Service Locator to find implementations of the command. The Command 
Manager creates an instance of thecCommand, loading the code if required. The command 
instance is returned to the caller. See FIG. 52. 

[000349] Execute Command. This scenario represents execution of a program or 
process on behalf of the calling program. This scenario is another adaptation of a classic 
software pattern, the Adapter Pattern. The Command object returned from the 
GetCommand scenario is an adapter ("wrapper") for an existing technology service. 

[000350] The Command object gives a standard interface to the application regardless 
of the underlying back end technology. The command manages the transformation from 
one data format to another. Additionally, the command object manages the connection to 
the back end and associated protocols. See FIG. 53. 

[000351] Messaging Scenario Analysis. The messaging scenario that is relevant to the 
Back End Connectivity - Messaging framework is to get messages from internal/external 
data sources and deliver the messages to consumers. See FIG. 54. The Messaging 
framework preferably provides an adapter for each type of data source. The adapter gets 
messages asynchronously from the data source and performs message/protocol 
transformation. In this section the relevant sequence diagram is depicted for each scenario. 

[000352] Subscription: See FIG. 55. 

[000353] Message Delivery: See FIG. 56. 

[000354] Component Analysis 

[000355] This section outlines a preferred Logical Interface Definition provided by 
Back End Connectivity. Note that the interface is defined at the logical level and hence 
describes the behavior to be offered, but not the specific physical messages. 

[000356] 3270 Component Analysis. This section outlines the Logical Interface 
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Definition provided by the BEC IF. BEC IF forwards the call to the 3270 Adapter. Note 
that the interface is defined at the logical level and hence describes the behavior to be 
offered, but not the specific physical messages. Guidelines on how the physical messages 
can be constructed are given in the Implementation Considerations section below. 

[000357] 3270 Logical Interface Definition. The BEC 3270 IF interface has the 
following preferred logical operations: 



TABLE 21 



Operation 


Parameters 


Return 


Behavior 


Execute 


Collection of Params 
containing "Initiate", 

cSession=NULL 

sCachelD, sTrans, sArgs, 

sFuncKey, 

sReserved 


Standardized data 
structure 

containing output 
of the transaction 


Executes the 
transaction on the 
mainframe (if the cross 
reference table 
specifies this 
transaction as cached 
and the cached copy is 
not available). 


Execute 


Collection of Params 
containing "Continue", 

cSession=NULL 

sCachelD, sTrans, 
sResponse, 

sFuncKey, 

sCursorPos, 

sReserved 




Executes the 
transaction on the 
mainframe (even if the 
cached copy of this 
transaction is 
available). 



[000358] RPC Component Analysis. RPC Logical Interface Definition: See FIG. 57. 

TABLE 22: CommandManager 



Operation 


Parameters 


Return 


Behavior 


GetCommand 


Command Identifier 
User Context 
Command SL 


Command interface 


Checks with 
Security Framework 
to ensure that 
resource is available 
to user context. If 
available, locate 
service and code if 
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required. If i 
multiple services 
exist, use SL to 
determine unique 
service instance. 



TABLE 23: Command 



Attribute 


Description 


CommandType 


The type of command. Values could be: stored 
procedure, dynamic SQL, XML request document. 


CommandText 


The text that represents the command. This could be 
a command name or call string. 



TABLE 24 



Operation 


Parameters 


Return 


Behavior 


Execute 


ParameterCollection 


ExecuteResults 


Executes the 
command on behalf 
of the application. 
The results are 
returned as Execute 
Results object. 


Transform 


None 


None 


Transforms the data 
for the command 
into a format 
understood by the 
underlying 
technology. 


GetParameters 


None 


Parameter 
Collection 


Returns a collection 
of parameters 
appropriate for the 
command. Clients 
set values for the 
parameters and pas 
as input to Execute 
method. 



TABLE 25: Connection 



Attribute 


Description 


ConnectionType 


The type of the connection, i.e.: ODBC, OLEDB, 
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TGADP, Web Service. 


ConnectionString 


Information about the connection required to 
connect 


Timeout 


The length of time to wait for a request before 
timing out the operation. 


TABLE 26: Parameter 


Attribute 


Description 


Name 


The name of the parameter 


Value 


The value assigned to the parameter 


Type 


The data type for the parameter. 


Direction 


The direction of the parameter. Valid values for 
direction are In, InOut, and Out. 



[000359] ParameterCollection is a class that contains a collection of Parameter 
instances. 

[000360] Messaging Component Analysis. This section outlines the Logical Interface 
Definition provided by the Messaging framework. Note that the interface is defined at the 
logical level and hence describes the behavior to be offered, but not the specific physical 
messages. 

[000361] Messaging Logical Interface Definition: The Messaging Connectivity 
Component realizes Adapter, Subscriber, and Publisher interfaces. The Subscriber interface 
object has the following logical operations: 



TABLE 27 



Operation 


Parameters 


Return 


Behavior 


Subscribe () 


Topic 


SUCCESS/ERR 
OR 


Accept messages with 
defined message type 
from the IF. 


UnSubscribe () 


Topic 


SUCCESS/ERR 
OR 


No longer want to 
receive messages from 
the Integration 
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Framework. 


CreateConnectionQ 


Username, 

Password, 

EFMessageServicel 
D, 

SubscriberlD 


SUCCESS/ERR 
OR 


Check for user 
entitlement 

Establish 
communication 
channel with the IF 
Pub/Sub System 


[000362] The Publisher interface object has the following logical operations: 

TABLE 28 


Operation 


Parameters 


Return 


Behavior 


CreateConnection () 


EFMessageServicel 
D, 

Topic 


SUCCESS/ERRO 
R 


Establish 
communication 
channel with IF - 
Pub/Sub System 


Publish 0 


Message, 
DeliveryMode, 
Priority, 
Timeout 


NIL 


Sends messages to the 

Integration 

Framework 


[000363] The Adapter interface object has the following logical operations: 

TABLE 29 


Operation 


Parameters 


Return 


Behavior 


GetMessageQ 


Message 


SUCCESS/ERR 
OR 


Get messages from 
data source 

Perform protocol 
transformation 

Transform message 
into a common 
message format 
understood by the 
underlying technology 



[000364] Naming Conventions. Commands provided in the Back End Connectivity 

Framework preferably adhere to standards for naming and structure. Standards provide for 
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easier readability, development, and support of the interfaces. 



[000365] Command Name: 

[000366] Interface: <Verb><AppCategory>[Optional: Subcategory] [Optional: 
Qualifier] 

[000367] Verb: Query, Create, Update, Delete, Execute 

[000368] AppCategories: Account, Research, Client, Order 

[000369] Subcategory 

[000370] Qualifier 

[000371] Example: QueryAccount, QueryAccountBalance, ExecuteOrder, 
DeleteAccountHolding, CreateResearchOpinion. 

[000372] Command Response: <CommandName>Response 

[000373] Example: QueryAccountResponse 

[000374] Command Return Data: <CommandName>Results 

[000375] Example: QueryAccountResults 

[000376] Implementation Considerations 

[000377] This section describes some of the considerations that preferably are taken 
into account while implementing services for back end connectivity. 

[000378] 3270 Protocol Considerations. The Datastream that is expected out of the 
3270 Connectivity Service is a standardized Data Stream representing 3270. 

[000379] BEC IF Adapter Namespace. The 3270 Adapter Namespace exposes two 
methods via Execute (method of BEC IF), viz., "Initiate" and "Continue." The method is 
either "Initiate" for Initial request or "Continue" for Continuation of User Response. This 
is recommended for the following reasons: 
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[000380] (1) If there is a cached copy of the transaction, it would be submitted as a 
response to this method "only" if it is an "Initial" request; otherwise, the request is routed to 
the Mainframe for execution. 

[000381] (2) If this is an Initial request, a 3270 Screen Buffer will be constructed (out 
of Transaction ID and the sArgs (see below)) and submitted to the mainframe. 

[000382] "Initiate" is used for Initiation of Mainframe transactions. Following is the 
signature of the method: Execute("Initiate", cSession=NULL, sCachelD, sTrans, sArgs, 
sFuncKey, sReserved) 

[000383] cSession: is the last character of the TermID ( used for executing this 
transaction). If this value is NULL, the adapter allocates an available session for use. 

[000384] sCachelD: is the key to cached transactions. Transaction ED cannot serve as 
an identifier since a user can have multiple copies of the same transaction with different 
states. (RCE is one transaction that can have as many as 400 branches. The value of Select 
fields denotes the branch that the user wants to follow.) 

[000385] sTrans : is the transaction to execute. 

[000386] sArgs : is a string that the Adapter concatenates with the sTrans (see above) 
and executed (much like a command line execution). For example, if the purpose was to 
execute "RCE 23a897655/l/2/3" in a "Clear" screen, the sTrans would have "RCE" and 
sArgs would have "23a89765/l/2/3." 

[000387] sFuncKey : Function Keys that were pressed (PF1 . . . PF12 and the 
Advanced PA keys). 

[000388] sReserved : Reserved Data. 

[000389] Response: The response is in a Standardized Data format. The data will 
contain all the fields that make up the resultant screen (including all relevant attributes like 
position, style, etc.), and choices. The Screen Buffer will be cached in Utility and will be 
accessed for future use. 
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[000390] 



(If Unsuccessful) 



[000391] Requested status and/or Warnings 

Error details 

[000392] Error ID, Error type (server, app.. etc) Error Message. 

[000393] OR 
[000394] (If Successful) 

[000395] Standardized Format representing 3270 Data Stream 

[000396] 3270 Map 

[000397] "Continue" is used for Continuation of Response. Following is the 
preferred signature of the method: Execute( "Continue", sSession, sCachelD, sTrans, 
sResponse, sFuncKey, sCursorPos, sReserved ) 

[000398] cSession: is the last character of the Termid ( used for executing this 
transaction). If this value is NULL, the adapter allocates an available session for use. 

[000399] sCachelD: is the key to cached transactions. The response to this request 
will be saved using this identifier. 

[000400] sTrans: Transaction to execute. 

[000401] sResponse: Name-Value pairs of the user response in the editable fields. 
Each edit field will have a name that starts with the letter C E' (for edit field) followed by 
row number, a "_" and a column number. For example, "El_10" denotes the edit field on 
first row, 10 th column. A semicolon will delimit the name-value pairs. 

[000402] sFuncKey: Function Keys that were pressed ( PF1 ... PF12 and the Advanced 
PA keys). 

[000403] sCursorPos: Edit field that has the cursor position. The name of the edit 

field conforms to the same format that is stated in sResponse. 
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[000404] sReserved: Reserved Data. 



[000405] Response: The response is in a Standardized Data format. The data will 
contain all the fields that make up the resultant screen (including all relevant attributes like 
position, style, etc.), and choices. The Screen Buffer will be cached in Utility and will be 
accessed for future use. 

[000406] (If Unsuccessful) 

[000407] Requested status and/or Warnings 

Error details 

[000408] Error ED, Error type (server, app, etc.) Error Message. 

[000409] OR 
[000410] (If Successful) 

[000411] Standardized Format representing 3270 Data Stream 

[000412] 3270 Map 

[000413] RPC Protocol Considerations: The back end connection framework 
preferably does not restrict the wire protocol used for connectivity. The framework requires 
that standard protocols such as SOAP be used. Applications using the framework do not 
decide the protocol and are not aware of the implementation details of the protocol. 

[000414] Messaging Protocol Considerations: Messaging Connectivity Namespace. 
This is a preferred minimum requirement for the messaging framework namespace. 

[000415] Exemplary Common Message Header Format: 

VERSION = 0101 

MCAT = MESSAGE CATEGORY, A = HOST ALERT, L = LOCAL ALERT, P = HOST 
PRINT 

MTYPE = CURRENT TGA MESSAGE TYPES, I.E., AOI, FYI, ETC. 
MSRC = ORIGINATION SYSTEM, I.E. FYI, ORDER ENTRY, ETC. 
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MLOC_WC = ORIGINATION SYSTEM LOCATION/WIRE CALL, IF ANY 
(GENERATED EXTERNAL TO MAINFRAME HOST). 

MUSER = ORIGINATION SYSTEM USER ID, IF ANY. 

MID = MESSAGE ID (UNIQUE) 

TIMESTAMP = TIMESTAMP (MMDDYYYYHHMMSSSS) WHEN THIS MESSAGE 
ENTERED 

DETAIL = ONE LINE MESSAGE TITLE OR DESCRIPTION 

ADDRESSING. MODE = ADDRESSING MODE, I = INDIVIDUAL, X = BROADCAST 
TO ALL AT WC 

ADDRESSDSfG.COUNT = COUNT OF RECIPIENTS 

ADDRESSING.LOC_WC = WIRE CALL WHERE MESSAGE IS TO GO 

ADDRESSING. TYPE = ADDRESSING TYPE, N = NTID, B = BOSS ID, V = VENDOR 
SPECIFIED. 

ADDRESSING.RECIPIENT.USER 1 TO N USER ID'S 

MSG.CAT = CURRENT TGA MESSAGE CATEGORIES, I.E., MG - MANAGEMENT, 
ETC. 

MSG.DETAIL = DETAIL FOR MESSAGE CAT, SUCH AS TD' FOR FUNDS DUE 

MSG.DATETIME = MESSAGE DATE/TIME MMDDYYYYHHMMSSSS PROVIDED 
BY INPUT SYSTEM. 

MSG.LEN = NUMBER OF CHARACTERS rN MESSAGE 

MSGLINES = NUMBER OF LINES IN MESSAGE 

MSG.DATA.NL = 1 TO ADMS_OUT.MSG.LINES OF TEXT DATA 

RESENT = 0 TO N TIMES MESSAGE HAS BEEN RESENT TO DELIVERY SYSTEM 

[000416] Delivery Mode: Asynchronous request-reply, Persistent. 

[000417] Topic: branch location code 

[000418] Message Payload : Message output header + Message Text 

[000419] Message output header: RTRV/POSS DUP 
[000420] DEST OSN [SO ISN] D/T 



APPENDIX A: 3270 Field Attributes 
TABLE 30 
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Line 


Field Description 


Application Screen View 


1 


Protected unmarked fields 
prior to first enterable field or 
first FSET protected field. 


Ignored for View. 


1 


First unprotected field unless 
FSET protected field 
encountered first. 


Taken to be Function field. Not mapped 
directly to view, but used for transmitting 
Transaction ID. 


1 


FSET protected field prior to 
first unprotected field. 


Taken to be Function field. Response data 
considered invalid if contents of this field do 
not match the Transaction ID attribute of the 
Page. 


1 


First FSET protected field 
between Function field and 
next enterable field. 


Taken to be Hidden function field. If any 
transmission is made with the function field of 
the Host data map blank, this field must be 
present and nonblank. 


1 


Next unprotected field, or 
second FSET field, after 
Function Field. 


Taken to be Select field. If field is FSET 
protected, the screen will have to be cleared if 
WS User alters the Select field on the View. 


1 


Next unprotected or FSET 
field after the Select field. 


Taken to be the Password field. If field is 
FSET protected, the screen will have to be 
cleared if the WS User alters the Password field 
on the View. 


2- 
19 


Any protected, displayable 
field. 


Presented as text in client area of Application 
Screen View, in location expected on a 3270 
disnlav Color of text t>er table below. 


2- 
19 


Any protected, hidden field. 


Ignored for View. If FSET, WHAM will 
retransmit to Host application. 


2- 
19 


Any unprotected, single-line 
displayable field. 


Presented as an edit control on Application 
Screen View, in location expected on a 3270 
display. Color of text per table below. 


2- 
19 


Any unprotected, single-line 
nondisplayable field. 


Presented as a password-style edit control on 
Application Screen View, in location expected 
on a 3270 display. Displayed masking 
character configurable in Registry. 


2- 
19 


Any unprotected, multi-line 
displayable field 


Presented as a single editable object that wraps 
from the end of one line to the beginning of the 
next in the way expected on a 3270 display. 
However, if field extends beyond line 19, it is 

, . 1 lit 1 ft' 1 A S~~\ 1 f* J. J. 

truncated at the end of line 19. Color of text 
per table below. 


2- 


Any unprotected, multi-line 


Presented as a single-line password-style edit 
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Line 


Field Description 


Application Screen View 


19 


nondisplayable field. 


control on Application Screen View, capable of 
horizontal scrolling to hold the number of 
characters required by the 3270 field. If the 
field contains at least one full line, it is 
displayed on the first such line, as a field of 80 
characters. If the field does not contain a full 
line (thus occupying at most two lines), it is 
displayed on the line on which it has the most 
enterable characters. If it has the same number 
of characters on each of the two lines, the field 
is displayed on the second line, where is starts 
at the beginning of the line. Displayed masking 
character configurable in Registry. 


20- 
24 


Text of a given line, ignoring 
field boundaries. 


If non-blank, presented as one line of a multi- 
line rich text edit field (with user editing 
disabled)., with text colors established 
separately for each field originally in the 3270 
map, according to the table below. Blank or 
hidden fields are ignored in the View. ; 


20- 
24 


Any unprotected fields. 


If non-blank, contents are presented as text per ' 
rule above, but WS User cannot alter contents. 
Blank or hidden fields are ignored in the View. 



[000421] The colors of the text characters are determined from Table 31 below. 

TABLE 31 



3270 Display Attribute 


3270 

Extended 
Attribute 


Hex 
Code 


Color in Application View 


Hidden (a/k/a Non- 
display) and protected. 


Any 




Ignored, because text is not 
displayed. 


Hidden (a/k/a Non- 
display) and 
unprotected. 


None or Color 
Neutral 


42F0 


Black (color of displayed masking 
character). 


Normal, non-detectable 


None or Color 
Neutral 


42F0 


Black (0,0,0) 


Normal, selector pen 
detectable 


None or Color 
Neutral 


42F0 


Configurable, default Purple 
(199,21,124) 


Intensified 


None or Color 


42F0 


Configurable, default Red 
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3270 Display Attribute 


3270 

Rxtended 
Attribute 


Hex 
Code 


Color in Application View 




Neutral 




(255,0,0) 


Any but Hidden 
protected 

1-/1 KJ L w V> L ^ V.1 • 


Color Blue 


42F1 


Blue (0,0,255) 


Any but Hidden 
protected 


Color Red 


42F2 


Red (255,0,0) 


Any but Hidden 
protected 


Color Pink 


42F3 


Magenta (192,0,192) 


Any but Hidden 
protected 


Color Green 


42F4 


Green (0,255,0) 


Any but Hidden 
protected 


Color 
Turauoise 


42F5 


Cyan (0,192,192) 


Any but Hidden 
protected 


Color Yellow 


42F6 


Yellow (192,192,0) 


Any but Hidden 
protected 


Color Neutral 


42F7 


Configurable, matches 
background color, default 
(208,208,208) 


Any but Hidden 
protected 

LJl \J Ivv LvU 


Color Black 


42F8 


Black (0,0,0) 


Any but Hidden 
protected 

yj x \j ivv. ivu 


Color Deep 
Blue 


42F9 


Deep Blue (0,0,96) 


Any but Hidden 
protected 


Color Orange 


42FA 


Orange (255,192,0) 


Any but Hidden 
protected 


Color Purple 


42FB 


Purple (199,21,124) 


Any but Hidden 
protected 

L/lV/lvv IvU 


Color Pale 
Green 


42FC 


Pale Green (128,255,128) 


Any but Hidden 
protected 


Color Pale 
Turauoise 


42FD 


Pale Turquoise (128,255,255) 


Any but Hidden 
protected 


Color Grey 


42FE 


Grey (128,128,128) 


Any but Hidden 
protected 


Color White 


42FF 


White (255,255,255) 


Any but Hidden 
protected 


Extended 
Highlight 
Blink 


41F1 


Ignored 
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[000422] Although the present invention is particularly beneficial for use with 
business-related networks, it should be understood that the invention is not limited in that 
regard. Accordingly, the present invention may also be used with any type of software- 
based system that has front-end applications interacting with back-end services. 
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